Methods and System for Securely Capturing and Providing Transaction Information

ABSTRACT

An option is set on a payment card of a card issuer. A request for payment for a transaction is received by a payment server of the card issuer from a merchant device/server. The payment server requests and receives a one-time token based on the option. An authorization indicating payment was successful is sent from the payment server to the merchant device/server with a flag set, the token, and a network address. Merchant device/server identifies the flag obtains the token and sends an e-receipt for the transaction along with the token to the network address. The e-receipt accessible from the network address by a consumer associated with the transaction. Furthermore, the e-receipt is obtained by the consumer without registering personal information or contact information with the merchant, which preserves the anonymity of the consumer with respect to the merchant.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a division of U.S. patent application Ser. No.17/084,969, filed Oct. 30, 2020, which application and publication isincorporated herein by reference in its entirety.

BACKGROUND

Many businesses provide corporate credit cards to their employees forbusiness-related expenditures. However, the employees must maintainproper receipts and records to justify their expenditures, which isproblematic for a variety of reasons.

The employees often lose or misplace their monthly corporate cardreceipts, which can delay businesses from approving expenditures of theemployees. In such situations, an employee may be denied reimbursementfrom his employer in cases where the employee is responsible for payingthe credit card balance each month or an employer may demandreimbursement from the employee in cases where the employer pays thecredit card balance each month on behalf of the employee.

Typically, the transaction information associated with an employeepurchase is only available in a summarized and condensed format by thecorporate card issuer. The level of detail provided by the merchant tothe corporate card issuer is usually deficient for tax purposes andsometimes bears no resemblance to the actual transaction receiptprovided by the merchant to the employee after a transaction. For mostemployers and for most transactions, the merchant to card issuertransaction detail is not a proper or an acceptable transaction receiptto justify and employee's purchase for tax purposes.

Furthermore, many consumers often desire to keep track of their monthcredit card purchases independent of any employer-related expenses.Often the only way that a consumer can maintain a monthly record is toindividually sign up with each of the various merchants to haveelectronic receipts sent to the consumer or to take a photograph of thereceipt and then manually assemble all the photographs for all receiptsat the end of the month. But many consumers are reluctant to providemerchants with personal email addresses and/or personal phone numbersdue to privacy concerns and due to the fear that the consumers will beoverwhelmed with spam emails or spam text messages from the merchantsand partners of those merchants.

SUMMARY

In various embodiments, methods and a system for securely capturing andproviding transaction information.

According to an aspect, a method for securely capturing and providingtransaction information is presented. A token request for a transactionand a value linked to an account of a consumer are received from apayment server associated with a card issuer for a payment card beingused as payment for the transaction by the consumer at a merchant deviceor a merchant server. The token is generated and provided back to thepayment server. The token and an electronic receipt (e-receipt) areobtained for the transaction from the merchant device of the merchantserver. The e-receipt for the transaction is linked to the account ofthe consumer for access by the consumer based on the token.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a system for securely capturing and providingtransaction information, according to an example embodiment.

FIG. 2 is a diagram of a method for securely capturing and providingtransaction information, according to an example embodiment.

FIG. 3 is a diagram of another method for securely capturing andproviding transaction information, according to an example embodiment.

DETAILED DESCRIPTION

FIG. 1 is a diagram of a system 100 for securely capturing and providingtransaction information, according to an example embodiment. It is to benoted that the components are shown schematically in greatly simplifiedform, with only those components relevant to understanding of theembodiments being illustrated.

Furthermore, the various components (that are identified in the FIG. 1 )are illustrated and the arrangement of the components is presented forpurposes of illustration only. It is to be noted that other arrangementswith more or less components are possible without departing from theteachings of securely capturing and providing transaction informationpresented herein and below.

As will be discussed more completely herein and below, system 100provides secure and private mechanism by which employees and consumerscan access and receive merchant transaction receipts electronically. Theelectronic receipts are available in near real time to the employees andthe consumers and the private information related to the payment cards,computing devices, and electronic identifiers of the employees andconsumers are not exposed to nor shared with the merchants.

System 100 comprises a cloud/server 110, a payment server 120, amerchant device or server 130, and a user-operated device 140.

Cloud/server 110 comprises a processor 111 and a non-transitorycomputer-readable storage medium 112. Medium 112 comprises executableinstructions for an account manager 113 and a token/ApplicationProgramming Interface (API) manager 114.

Payment server 120 comprises a processor 121 and a non-transitorycomputer-readable storage medium 122. Medium 122 comprises executableinstructions for a token requestor 123 and a payment manager 124.

Merchant device or server 130 comprises a processor 131 and anon-transitory computer-readable storage medium 132 having executableinstructions comprising a transaction manager 133 and API 134.

User-operated device 140 comprises a processor 141 and a non-transitorycomputer-readable storage medium 142 having executable instructionscomprising an account 143.

Each processor of each device/server when provided the correspondingexecutable instructions from the corresponding medium causes thatprocessor to perform operations associated with the corresponding113-114, 123-124, 133-134, and 143), as discussed below with accountmanager 113, token/API manager 114, token requestor 123, payment manager124, and account interface 143.

During a conventional transaction between a consumer and a merchant whenthe payment method being used by the consumer is a payment card, theconsumer provides the card details to the merchant and the merchantsends the transaction total price due and card details (which may beencrypted) to the card issuer for payment processing. The card issuersends back an authorization or denial to the merchant in real time andassuming the authorization was received, the merchant provides a printedtransaction receipt to the consumer or if the consumer is registered forelectronic receipts (e-receipts), the merchant emails or texts theelectronic receipt to the consumer. The merchant typically does not senda complete transaction receipt to the card issuer; thus, the onlycomplete record the consumer has for the transaction is a printedreceipt or an electronic receipt assuming the consumer is comfortablewith sharing some personal information (mobile phone number or emailaddress) with the merchant and has registered with the merchant. Thisconventional process is changed with system 100 and the teachingsprovided herein.

Initially, the consumer is registered with a card issuer. Consumer'swith payment cards are required to be registered with contact detailswith the card issuers, in fact government regulations require suchregistrations with the full legal name or entity associated with theconsumer along with contact information for the consumer. So, thisregistration is already in place between the consumer and the cardissuer. The card issuer modifies its consumer-facing interface to allowthe consumer to indicate that the consumer desires to have merchantreceipts for the consumer's payment card transactions maintainedsecurely. This option is maintained on the consumer's account by thecard issuer within a profile for the consumer.

The card issuer maintains payment server 120 for processing paymentsreceived by merchant device or server 130. During a transaction betweena consumer and merchant device or server 130, the transaction items oronline cart are processed and tabulated by transaction manager 133. Whenpayment is due, the consumer provides the payment card for payment andtransaction manager 133 sends the payment card details (may beencrypted) and total transaction price over a secure network connectionto payment manager 124. Payment manager 124 looks up the card detailsand identifies the account of the consumer. The profile linked to theaccount is obtained and the option for e-receipts is detected.

Token requestor 123 sends a message to token/API manager 114 requestinga one-time token and API location for sending the e-receipt for thetransaction. Token/API manager 114 generates the one-time or one-usetoken and associates it with an account of the consumer via accountmanager 113 and sends the generated token and the API location back totoken requestor 123. Token requestor provides the token and API locationto payment manager 124. Payment manager 124 performs payment processingon the transaction with the consumer account and sends an authorizationwith a flag set indicating the consumer associated with the transactionis requesting an e-receipt from the merchant. The authorization and setflag also include the token and API location.

Transaction manager 133 detects the set flag on the authorization andpasses the e-receipt, the token, and the API location to API 134. API134 attaches the token to the e-receipt and sends to the API location,which results in token/API manager 114 receiving the e-receipt and tokenfrom merchant device of server 130.

Token/API manager 114 posts the e-receipt to a cloud-based locationlinked to an account of the consumer. The consumer can log into anaccount associated with payment server 120 and/or a separate accountwith cloud/server 110 and view all the e-receipts of the consumer forthe corresponding payment card associated with all transactions that theconsumer had with multiple disparate merchants via account interface 143from any user-operated device 140.

It is noted that once token/API manager 114 uses the token to link thee-receipt of the consumer to the consumer's account, the token isdiscarded and is no longer needed, such that token/API manager 114 doesnot need to retain any mapping between the token and the account of theconsumer.

At no time, during the above-noted processing, is any personalinformation of the consumer disclosed or made available to the merchantor merchant device or server 130. As such, the consumer can manage andreview transaction information or e-receipts for transactions in acentralized location, such transactions can span multiple differentmerchants.

A variety of variations on the above-noted processing can occur. Forexample, an account for the consumer with cloud/server 110 may includean option for the consumer to have each e-receipt sent in real time to aconsumer-registered email address or a consumer-registered mobile phone(via a text message). The email or text message may include a link thatwhen accessed provides a complete listing of all e-receipts.

In another example, the processing associated with cloud/server 110 maybe subsumed in its entirety within payment server 120, such that thee-receipts functionality is available just through the card issuer.

In an embodiment, there may be multiple payment servers 120, eachpayment server 120 representing a different card issuer for a differentpayment card used by the consumer. In this embodiment, when the consumeruses account interface 143 to log into cloud/server 110, the consumercan view e-receipts for all cards of the consumer and filter thee-receipts for viewing by a particular payment card or grouping ofselect payment cards.

In an embodiment, payment server 120 does not send payment card detailsfor a payment card of the consumer over a network connection betweenpayment server 120 and cloud/server 110. In this embodiment, token/APImanager 114 includes a registered payment card that the consumerregistered with cloud/server 110 to link a given token to the paymentcard associated with a given transaction. Also, token requestor 123 isequipped with a hash algorithm known to token/API manager 114, such thattoken requestor 123 sends a hash value of the consumer's payment cardgenerated by the hash algorithm to token/API manager 114, and the tokengenerated for a given transaction by token/API manager 114 can use thehash value to associate the generated token with the payment cardregistered to the consumer for the card issuer. It is noted that theconsumer may register the payment card but the payment card details isnot retained by account manager 113 nor token/API manager 114 oncloud/server 110; rather, once the payment card details are supplied fora consumer registering a payment card, the hash algorithm is used tocalculate the hash value (which is retained by account manager 113) andthe initially provided payment card details are deleted and removed frommemory and storage on cloud/server 110.

In a similar embodiment to what was discussed above, payment server 120may provide a mechanism by which the consumer can associate a uniquepersonal identification number (PIN) provided by the consumer or havepayment server 120 generate a permanent token on behalf of the consumerwhen the consumer selects an e-receipt option for merchant transactions.Here, the consumer uses account interface 143 when creating an accountwith account manager 113 to provide the PIN or the permanent token,which is retained by account manager 113 as a reference to a registeredpayment card of the consumer. In this embodiment, token requestor 123provides the PIN or the permanent token to token/API manager 114 whenmaking a request for a one-time transaction token for a giventransaction. In this embodiment, the payment card details for thepayment card of the consumer are never disclosed, known to, or availablefrom cloud/server 110.

In an embodiment, account manager 113 may allow the consumer toauthorize other accounts with cloud/server 110 to view e-receipts of theconsumer for a specifically designated consumer payment card. Thispermits an employer of the consumer to view e-receipts for transactionswith merchants performed by the consumer, such that theconsumer/employee does not have to provide any justification or receiptsto his/her employer for the transactions because the employer utilizingan employer account to cloud/server 110 can view the employee'stransactions independent of any action of the employee.

In a related embodiment to the previous embodiment, account manager 113may provided automated reporting of an employee's e-receipts on anemployer-defined recurring interval of time. At the designated recurringintervals of time, account manager 113 assembles all the employeese-receipts associated with the employer-issued payment card and pushesthe e-receipts to an email designated by the employer or posts thee-receipts to a network location designated by the employer.

In an embodiment, the e-receipts may also be enhanced to allow merchantsto deliver promotions to the consumer in an anonymous fashion thatretains the privacy of the consumer (without the merchant knowing theidentity of the consumer and without the merchant having any identifyinginformation for the consumer). In this embodiment, the consumer providesan option on the consumer's profile with payment server 120 thatauthorizes delivery of merchant promotions, when payment manager 124sends the flagged authorization for a given transaction along with thetoken to transaction manager 133 another flag is set that authorizesproviding promotions to the consumer. API 134 then sends the token andthe e-receipt along with any e-rebates or e-discounts to token/APImanager 114. Token/API manager 114 links the e-receipt and e-rebates ore-discounts to an account of the consumer (in any of the mannersdiscussed above), when the consumer logs into cloud/server 110, theconsumer can view and obtain both e-receipts and e-rebates ore-discounts being offered anonymously by the merchant to the consumer.This allows the consumer to receive promotions from merchants withoutdisclosing personal information and without registering as a customerwith the merchant. It is noted that two separate tokens may be used aswell, such that a consumer authorizing promotions causes token requestor123 to request two tokens that are generated by token/API manager 114for a given transaction and API 134 provides the two tokens back totoken/API manager 114; one token associated with e-receipts and onetoken associated with promotions.

In an embodiment, merchant device 130 is a Self-Service Terminal (SST),a Point-Of-Sale (POS) terminal, an Automated Teller Machine (ATM), akiosk, a wearable processing device, a laptop, or a mobile phone.

In an embodiment, the API location provided with the paymentauthorization from payment manager 124 is a Uniform Resource Locator(URL) link comprising a network address for cloud/server 110.

In an embodiment, merchant server 130 is an online transaction serverassociated with a merchant for online transactions.

In an embodiment, user-operated device 140 is a phone, a tablet, alaptop, a desktop, a wearable processing device, a voice-enabled networkdevice (Amazon® Echo®, Google® Home®, etc.), an intelligent appliance,an vehicle integrated computing device, or an Internet-of-Things (IoT)device.

These and other embodiments are now discussed with reference to FIGS.2-3 .

FIG. 2 is a diagram of a method 200 for securely capturing and providingtransaction information, according to an example embodiment. Thesoftware module(s) that implements the method 200 is referred to as a“secure transaction information manager.” The secure transactioninformation manager is implemented as executable instructions programmedand residing within memory and/or a non-transitory computer-readable(processor-readable) storage medium and executed by one or moreprocessors of a device. The processor(s) of the device that executes thesecure transaction information manager are specifically configured andprogrammed to process the secure transaction information manager. Thesecure transaction information manager has access to one or more networkconnections during its processing. The network connections can be wired,wireless, or a combination of wired and wireless.

In an embodiment, the device that executes the secure transactioninformation manager is server 110. In an embodiment, the server 110 is acloud processing environment that comprises multiple servers cooperatingwith one another as a single server 110 (representing a cloud 110).

In an embodiment, the secure transaction information manager is all ofor some combination of 123-124 and/or 113-114.

In an embodiment, the secure transaction information manager performsthe processing discussed above with system 100.

At 210, the secure transaction information manager receives a tokenrequest for a transaction and a value linked to an account for aconsumer from a payment server associated with a card issuer for apayment card used as payment for a transaction by the consumer at amerchant device or a merchant server.

In an embodiment, at 211, the secure transaction information manageridentifies the value as a payment card account that is linked to theaccount.

In an embodiment, at 212, the secure transaction information manageridentifies the value as a hashed value associated with a payment cardaccount that is linked to the account.

In an embodiment, at 213, the secure transaction information manageridentifies the value as a PIN, or a permanent token associated with thepayment card. The PIN or the permanent token is linked to the account.

At 220, the secure transaction information manager generates the token.

In an embodiment, at 221, the secure transaction information managergenerates the token as a single use and one-time token associated withthe token.

At 230, the secure transaction information manager provides the token tothe payment server.

At 240, the secure transaction information manager obtains the token andan e-receipt for the transaction from the merchant device or themerchant server.

In an embodiment of 221 and 240, at 241, the secure transactioninformation manager discards the token once the account is identifiedusing the token.

In an embodiment, at 242, the secure transaction information managerreceives an electronic promotion from the merchant device or themerchant server with the e-receipt.

At 250, the secure transaction information manager links the e-receiptto the account of the consumer for access by the consumer based on thetoken.

In an embodiment of 242 and 250, at 251, the secure transactioninformation manager links the electronic promotion to the account basedon the token for access by the consumer.

In an embodiment, at 252, the secure transaction information managerprovides an interface to a consumer-operated device for accessing theaccount and viewing the e-receipt associated with the transaction andother e-receipts associated with other transactions performed by theconsumer with other merchant devices or other merchant servers that usedthe payment card as payments for those other transactions.

In an embodiment, at 260, the secure transaction information managerprovides access to the e-receipt and other e-receipts associated withthe payment card to a user that is associated with different accountfrom the account of the consumer based on an authorization associatedwith the account of the consumer.

In an embodiment of 260 and at 270, the secure transaction informationmanager periodically assembles the e-receipt and the other e-receipts,and the secure transaction information manager dynamically pushes thee-receipts and the other e-receipts to an email address or a networklocation associated with the user based on settings on the differentaccount associated with the user.

In an embodiment, at 280, the secure transaction information managerdynamically pushes the e-receipt to an email address, or a mobile phoneassociated with the consumer based on settings on the account associatedwith the consumer.

FIG. 3 is a diagram of another method 300 for securely capturing andproviding transaction information, according to an example embodiment.The software module(s) that implements the method 300 is referred to asan “e-receipt manager.” The e-receipt manager is implemented asexecutable instructions programmed and residing within memory and/or anon-transitory computer-readable (processor-readable) storage medium andexecuted by one or more processors of a device. The processors thatexecute the e-receipt manager are specifically configured and programmedto process the e-receipt manager. The e-receipt manager has access toone or more network connections during its processing. The networkconnections can be wired, wireless, or a combination of wired andwireless.

In an embodiment, the device that executes the e-receipt manager isserver 110. In an embodiment, the server 110 is a cloud processingenvironment that comprises multiple servers cooperating with one anotheras a single server 110 (representing a cloud 110).

In an embodiment, the e-receipt manager is all or some combination of123-124, 113-114, and/or the method 200.

The e-receipt manager presents another and, in some ways, enhancedprocessing perspective to that which was described above with the FIG. 2.

At 310, the e-receipt manager receives a request for storing transactioninformation for a consumer from a payment server during a transactionbetween the consumer and a merchant.

At 320, the e-receipt manager generates a one-time use token that islinked to an account of the consumer.

At 330, the e-receipt manager provides the one-time use token and anetwork location for a merchant device or a merchant server associatedwith the merchant to send the transaction information for storage.

At 340, the e-receipt manager receives the one-time use token from themerchant device or the merchant server.

In an embodiment, at 341, the e-receipt manager identifies an e-receiptwith the transaction information for the transaction.

In an embodiment of 341 and at 342, the e-receipt manager identifies amerchant provided electronic promotion provided by the merchant with thetransaction information.

At 350, the e-receipt manager maintains the transaction information andother transaction information of the consumer with the payment card atthe network location for viewing by the consumer and for reporting asdirected by the consumer.

In an embodiment of 342 and 350, at 351, the e-receipt manager maintainsthe e-receipt and the electronic promotion separately with both thee-receipt and the electronic promotion linked to the account of theconsumer.

In an embodiment, at 360, the e-receipt manager reports the transactioninformation to a resource designated by the consumer within a profile ofthe account.

In an embodiment, at 370, the e-receipt manager reports the transactioninformation to a device or a messaging account identifier for amessaging account associated with the consumer.

It should be appreciated that where software is described in aparticular form (such as a component or module) this is merely to aidunderstanding and is not intended to limit how software that implementsthose functions may be architected or structured. For example, modulesare illustrated as separate modules, but may be implemented ashomogenous code, as individual components, some, but not all of thesemodules may be combined, or the functions may be implemented in softwarestructured in any other convenient manner.

Furthermore, although the software modules are illustrated as executingon one piece of hardware, the software may be distributed over multipleprocessors or in any other convenient manner.

The above description is illustrative, and not restrictive. Many otherembodiments will be apparent to those of skill in the art upon reviewingthe above description. The scope of embodiments should therefore bedetermined with reference to the appended claims, along with the fullscope of equivalents to which such claims are entitled.

In the foregoing description of the embodiments, various features aregrouped together in a single embodiment for the purpose of streamliningthe disclosure. This method of disclosure is not to be interpreted asreflecting that the claimed embodiments have more features than areexpressly recited in each claim. Rather, as the following claimsreflect, inventive subject matter lies in less than all features of asingle disclosed embodiment. Thus, the following claims are herebyincorporated into the Description of the Embodiments, with each claimstanding on its own as a separate exemplary embodiment.

1. A method, comprising: receiving a request for anonymously storingtransaction information for a consumer from a payment server during atransaction between the consumer and a merchant; generating a token forthe transaction linked to an account of the consumer; providing thetoken and a network location for a merchant device or a merchant serverto send the transaction information for storage; receiving thetransaction information from the merchant device or the merchant server;and maintaining the transaction information and other transactioninformation associated with other transactions of the consumer linked toa payment card registered to the account of the consumer at the networklocation for viewing by the consumer and for reporting as directed bythe consumer.
 2. The method of claim 1 further comprising, reporting thetransaction information to a resource designated by the consumer withina profile of the account.
 3. The method of claim 1 further comprising,reporting the transaction information to a device or a messaging accountidentifier for a messaging account associated with the consumer.
 4. Themethod of claim 1, wherein receiving further includes identifying anelectronic receipt (e-receipt) with the transaction information for thetransaction.
 5. The method of claim 4, wherein identifying furtherincludes identifying a merchant-provided electronic promotion providedby the merchant with the transaction.
 6. The method of claim 5, whereinmaintaining further includes maintaining the e-receipt and theelectronic promotion separately with both the e-receipt and theelectronic promotion linked to the account of the consumer.
 7. Themethod of claim 1, wherein generating further includes generating thetoken as a one-time use token valid for just the transaction.
 8. Themethod of claim 1 further comprising: identifying a login from theconsumer to the account through an account interface; and providing thetransaction information for the transaction and the other transactioninformation for the other transaction to the consumer through theaccount interface.
 9. The method of claim 1, wherein receiving thetransaction information further includes receiving the token with thetransaction information and identifying the account based on the tokenlinked to the account.
 10. The method of claim 9, wherein maintainingfurther includes discarding the token.
 11. The method of claim 1,wherein receiving the transaction information further includes receivingthe transaction information as a posting made by the merchant device orby the merchant server to the network location, wherein the networklocation linked to and specific to the account of the consumer.
 12. Themethod of claim 1, wherein maintaining further includes maintaining ahash value unique to the payment card, wherein the hash value is linkedto the account without maintaining payment card details of the consumer.13. A method, comprising: generating a token unique to an account of aconsumer and linked to a payment card of the consumer responsive to atoken requested received from a payment server that is processing apayment on behalf of the consumer during a transaction of the consumerat a merchant device or through a merchant server; providing the tokenand a network storage location back to the payment server; and receivingtransaction receipt details for the transaction of the consumer at thenetwork storage location from the merchant device or from the merchantserver.
 14. The method of claim 13, wherein receiving further includesreceiving the token from the merchant device or from the merchant serverand identifying the account of the consumer from the token.
 15. Themethod of claim 14, wherein identifying further includes linking thetransaction receipt details on the network storage location with theaccount of the consumer.
 16. The method of claim 13, wherein receivingfurther include identifying a posting made by the merchant device of bythe merchant server to the network storage location, wherein the networkstorage location unique to and linked to the account of the consumer.17. The method of claim 13 further comprising, maintaining thetransaction receipt details with other transaction receipt detailsassociated with other transactions of the consumer in the networkstorage location and linked to the account of the consumer.
 18. Themethod of claim 17 further comprising, providing an account interfacefor the consumer to login to the account for viewing and obtaining thetransaction receipt details and the other transaction receipt detailsfrom the network storage location.
 19. The method of claim 13, whereinproviding further includes providing the token as a one-time use tokenunique to the transaction and discarded once the transaction receiptdetails are provided at the network storage location.
 20. A system,comprising: a server comprising at least one processor and anon-transitory computer-readable storage medium; and the non-transitorycomputer-readable storage medium comprising instructions, which whenexecuted by the at least one processor cause the at least one processorto perform operations, comprising: generating a token linked to apayment card and an account of a consumer responsive to a token requestreceived from a payment server associated with the payment card duringpayment by the consumer for a transaction being processed for theconsumer on a merchant device or on a merchant server; providing thetoken and a network storage location to the payment server; andreceiving transaction receipt details for the transaction of theconsumer at the network storage location from the merchant device orfrom the merchant server.
 21. The system of claim 20, wherein the serveris a cloud server; wherein the merchant device is an automated tellermachine, a self-service terminal, or a point-of-sale terminal, andwherein the merchant server is a transaction server that performs thetransaction as an online transaction through interaction with aconsumer-operated device.